创始人 3 天狂砍 5 万行代码，网友：我给屎山加料，老板负责删
↓推荐关注↓
转自：infoQ，英文：Aakash N S，翻译：刘雅梦
软件开发和数据科学学习平台 Jovian 的创始人兼首席执行官、前 Twitter 软件工程师 Aakash N S 日前发文表示，自己在 Jovian 的代码库中删除了 5 万多行代码，这些代码占前端代码库的 70%。让人惊喜的是，删完这些代码后并没有破坏应用程序，也几乎没有造成任何实质性的损失，反而使得应用程序和代码库彻底简化，平台更轻、更容易使用。
正如 Antoine de Saint-Exupery 所言：“达到完美，不是没有东西可添加了，而是再也没有什么可去掉时”。软件开发也是一样的道理，有些时候，化繁为简才会让软件变得更好。
最近，我从 Jovian 的代码库中删除了 50000 多行代码，这些代码之前都在生产环境中运行，为我们的 Web 应用程序提供支持，该 Web 应用程序每天处理数十万个请求。被删除的代码约占我们前端代码库的 70%，是用 React 和 Next.js 编写的 JavaScript。
我惊喜地发现，我可以在短短的三天内删除超过三分之二的代码，并且完全不会破坏应用程序。然而，我发现更令人惊讶的是，在这个过程中，几乎没有任何实质性的损失。另一方面，清理导致了应用程序和代码库的彻底简化，使得平台更轻、更容易使用了。
自 2019 年以来，我们一直在构建 Jovian，多年来该平台经历了各个不同的发展阶段。我们在需要的时候添加了新功能、页面、按钮和设置，但我们却很少考虑删除（谁会这么做呢？）。我们有意识地努力保持应用程序的简单易用性，但它还是积累了很多“功能债”。
我曾在某处读到过，在一个典型的软件应用程序中，80% 以上的功能几乎从未被使用过，我记得看到过这张截图，该图显示了 Microsoft Word 中所有可用的工具：
虽然 Jovian 的情况并没有那么糟糕，但复杂的应用程序和庞大的代码库确实会使变更、升级库和添加可能真正重要的新功能变得困难。
几周前，我开始实验性地重写我们的 Web 应用程序，使用最新版本的 Next.js 构建，并部署到 Cloudflare Pages。我很快意识到，从头开始全面重写是行不通的。重新构建整个应用程序需要花费几个月的时间，而且几乎可以肯定，它会导致数百个缺陷。大爆炸式的迁移很少能奏效，即使奏效，也会比计划的时间要长得多。我在 Twitter 工作时亲身体验过了，在那里我花了几个月的时间将代码从 Ruby on Rails 迁移到 Scala。
然而，增量迁移也会带来了一系列的挑战。我创建的新页面在结构和内容上都非常简单，而我们应用程序中的现有页面有多个交互式选项卡、按钮和小部件。我们现有的 Web 应用程序使用由 Python 后端提供的 REST API，而我想利用 server actions 直接通过 Next.js 与我们的数据库进行交互，以使应用程序更快，同时消除托管后端的成本。这需要将数百个包含数万行重要业务逻辑的 API 端点从 Python 迁移到 JavaScript，而我并不希望这样做。
一时之间，似乎已经没有办法摆脱这种局面了。该应用程序及其代码库看起来就像是一头巨大的大象，只能缓慢而小步前进，它根本不愿意移动。每次在 VS Code 中打开代码库时，我都会遇到巨大的阻力，因为它所涉及的工作量实在是太多了。
然后，几天前，我突然意识到，通过减肥我可以走得更快。我可以从屏幕上删除不必要的小部件和按钮，将其迁移到新的技术栈（幸运的是，Next.js 支持增量迁移），然后再添加回删除的元素。然而，接下来发生的事情只能用“大屠杀”来形容：
我并没有打算删除代码库中三分之二的代码。我想删除的只是能足够开始迁移的一个模块而已。我通过 Google Analytics 查看了过去 30 天每个模块的页面访问量，以确定从哪里开始。虽然我知道有些页面的访问频率低于其他页面，但我惊讶地发现，有些模块的访问量占比不到总页面访问量的 0.1%。这意味着我可以完全删除它们，而不会影响 99.9% 的用户。我可以删除包含数十个文件和数千行代码的整个目录。
当我从应用程序的其余部分中删除了那些很少被使用的模块及其入口点时，我慢慢地发现应用程序变得越来越简单了，选项卡、页面和菜单项也越来越少了。删除未使用代码的感觉也很好。随着代码库变得越来越小，我对迁移的阻力和焦虑也开始减轻。最初，我对删除我们花了几周或几个月时间构建的模块而感到很难过，但我总能从 Git 历史中恢复我将来需要的任何东西。
在删除了那些很少被使用的整个模块后，我继续删除了占总流量不到 0.5% 的单个屏幕和弹出窗口。再次，我惊讶地发现，有数百个文件可以被删除，而不会影响 99.5% 的用户。事实上，这对用户也产生了积极的影响。五个选项卡变成了三个，然后是两个，再是一个，此时，选项卡可以完全从页面中删除。许多页面现在有了更直接的结构和单一的主要操作。更少的 API 调用导致更快的页面加载和屏幕转换。感觉好极了！
一旦删除了所有不必要的模块和页面，我就通过 Google Analytics 进一步挖掘，以确定剩余页面上的功能使用频率。我发现了一些很少使用的功能，几乎从未点被击过的按钮，甚至从未可见过的菜单项。所以，我开始删除它们。我拿走的越多，我就越喜欢剩下的。我删除了几个侧边栏、下拉菜单、按钮、小部件、弹出窗口以及支持它们所需的内部应用程序状态和条件逻辑。这也使得代码更易于理解了，这将进一步简化迁移。最初看似需要几个月的努力，现在感觉可以在几周内完成。
沉没成本谬论和损失厌恶是人类的偏见，使我们很难放弃不再需要的东西。我仍然担心我可能删除了太多或删除了一些重要的东西，但分析表明情况并非如此。今天访问该网站的用户数量与清理之前一样多，而且他们可以（并且正在）做和之前几乎一样的所有事情。毫无疑问，新用户会发现该平台更易于导航和使用了。
我知道每隔几年删除 70% 的代码可能会让很多其他应用程序受益。它能降低维护开销，使它们能够更快地移动，减少加载时间，并传送更小的包，同时改善用户体验，使软件变得更好。
原文链接：
https://aakashns.com/delete
- EOF -
觉得本文有帮助？请分享给更多人
推荐关注「算法爱好者」，修炼编程内功
点赞和在看就是最大的支持❤️